Looks good, but I do have a few comments.

There are many tests with a description similar to "Check that it is a compile-time error if an element type of a synchronous generator function f is not U, where S is a union-free type of the declared return type of f and S implements Iterable<U>"

I can't read that description. ;-)

First, there's no such thing as 'an element type' of a generator function, there is one specific type which is 'the element type' of that function. Next 'is not U' is far too flexible: There is an infinity of ways in which we can make the requirements true, and still satisfy 'is not U'.

So we'd have to say something like this:

"Check that if the declared return type of a synchronous generator function f is T, and S is the union-free type derived from T, and S is of the form Iterable<U>, it is a compile-time error to yield an expression whose static type isn't assignable to U."

But that's just the same thing as this:

"Check that for a synchronous generator function f with element type U which is not dynamic, it is a compile-time error to yield an expression whose static type isn't assignable to U."

With that, the 'asynchronous' variant would be achieved simply by replacing a space by 'n a'. ;-)

I think all the descriptions containing 'an element type' needs a similar adjustment, but please check all descriptions (I didn't confirm that they always contain 'an element type').

Next, there are many tests where we need to check that a given object has a run-time type that implements Iterable<T> for a specific T. Here is a way to perform that check:

// Testing method.

bool runtimeTypeImplementsIterableOf<X>(Object? o) {
  if (o is! Iterable<X>) return false;
  List<X> list = o.toList(growable: true);
  try {
    list.addAll(<X>[]);
  } on TypeError catch (_) {
    return false;
  }
  return true;
}

// Example usage.

void main() {
  Iterable<dynamic> xs = <num>[1];

  print(xs.runtimeType == List<num>); // 'false', it is some subtype.
  print(runtimeTypeImplementsIterableOf<Object>(xs)); // 'false'.
  print(runtimeTypeImplementsIterableOf<num>(xs)); // 'true'.
  print(runtimeTypeImplementsIterableOf<int>(xs)); // 'false'.
}

First, we can't use the runtimeType R of the target object o for anything: It's going to be some subtype of the statically known type, and it certainly won't be Iterable or List because they are abstract. Next, we can establish that R <: Iterable<X>. Finally, we need to ensure that the type argument of R at Iterable isn't a more special type (e.g., we wouldn't want to accept an object with run-time type that implements Iterable<Never>). We can do that by getting hold of the corresponding List (so it won't work if it is an infinite iterable, but I think we can handle that), and then test addAll.

I mentioned toList and addAll in several tests, but it's of course much better to have a standard testing function like the one above.

The current version of iterableElementsRuntimeIs might be trying to do a similar thing, but it won't work.

Tests updated. I renamed checking functions in Expect to Expect.isRuntimeTypeIterable and Expect.isNotRuntimeTypeIterable. Looks like this naming is more in consistance with the dart style. If you have better namig ideas, please let me know

I also preserved throwing exceptions by these functions. If we change it to return bool the we'll have to use Expect.isTrue(Expect.(isRuntimeTypeIterable(...)));. First, we never write a code this way (Expect.foo(Expect.baz(...))). Second, in case of failure we'll get an error Expect.isTrue(false) fails.. Expect.isRuntimeTypeIterable<int>(o); produces Not Iterable<int>: _SyncStarIterable<dynamic> which is much more informative

Still some things to think about. ;-)

I think it's really important to make an explicit distinction between o is Iterable<T> for some given T, and "the run-time type of o implements Iterable<T>", because the latter is strictly more demanding than the former. Based on that consideration, I've suggested a couple of renames.

Given that we're using a strong test, there is probably no need for isNotRuntimeTypeIterable at all, so I've suggested that it gets deleted.

Finally, a couple of descriptions still use the phrase 'an element type' of a function, or some other wording that is confusing.

LGTM!